An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hi, anyone has any updates on the recent App Store Review delays?

Hello, I have a problem regarding my App review. The issue: "Guideline 3.1.2 - Business - Payments - Subscriptions Issue Description The submission did not include all the required information for apps offering auto-renewable subscriptions. The app's metadata is missing the following required information: A functional link to the Terms of Use (EULA). If you are using the standard Apple Terms of Use (EULA), include a link to the Terms of Use in the App Description. If you are using a custom EULA, add it in App Store Connect." My explanation: I'm using Apple's original EULA in my app. The EULA was already in the "About" section. It redirects to the EULA page on Apple's official website. However, since my app also has a payment screen, I added the same information below the payment screen and submitted it for review again. Unfortunately, it's still being rejected for the same reason. I've requested a full, detailed explanation via email, but they keep sending me the same copy-and-paste message. I want to resolve this issue as soon as possible, so I decided to ask you here. Please check the screenshots and let me know what's the problem. Best regards, DryreL

Hello Apple Developer Community and App Review Team, Please help! Our app is "In Review" status for 4 days on a resubmission. We have requested an expedited review on 30 December because we had a launch with 20k users. My Apple ID: 6745441830 SKU: panduoapp This delay has pushed our planned launch back by over a week, impacting more than 20,000 pre-registered users who are waiting to access the app's core features (AI interactions, community, etc.). My developer had never seen this before and he got a new app submitted yesterday and got approved within 3 hours. Is this level of "In Review" time common right now during the post-holiday period? We've seen quick reviews on other similar apps recently, so wondering if this might be stuck or require a nudge. Any advice on next steps (beyond Resolution Center inquiry) or similar experiences? We've double-checked build attachment, IAP config, paywall links, and reviewer notes (including demo access). Thank you!

Hello everyone, I am facing a recurring issue with my app review and looking for advice. The Situation: I originally submitted a build last week and it sat in "Waiting for Review" for 7 days with no movement. Assuming it was a glitch, I removed that build and resubmitted this past Saturday (Jan 3). It is now Tuesday, and the new build is also stuck in "Waiting for Review" (no reviewer has picked it up yet). This is an update to an existing app. We have checked the Resolution Center and our email, but there are no messages or requests for more information from the App Review team. Has anyone else experienced similar delays recently? If an Apple staff member sees this, could you please check if there is an issue with the queue for this specific build? Thank you!

Our app have been waiting for a review for a whole day. We need this as soon as possible since it has a huge effect on our users' expereice. https://apps.apple.com/us/app/ziina-pay-get-paid-instantly/id1507246381

Hello, "This issue is blocking App store approval" I have tried pushing my application to Appstore. However it has been rejected on the following ground: _"As we discussed, the app uses or references the following non-public or deprecated APIs: Frameworks/CommonLibrary.framework/CommonLibrary Symbols: • _SecCertificateIsValid The use of non-public or deprecated APIs is not permitted, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms."_ I have scanned the app using "strings" tool & "otool -ov" tool. But they have come out clean. No Non-public or deprecated APIs detected. Please advise which tool can be used to scan the CL to locate where the deprecated API or non-public API lies and also how to rectify the same. Thanks Saikat Bakshi.

Hi everyone, I'm having a frustrating issue with in-app purchases on 2 of my apps, and despite following all the steps correctly, they're getting rejected during App Store review because the products screen doesn't load for reviewers. I could really use some help figuring out what I'm missing. What I've Done (Following Apple's Documentation) Created products in App Store Connect: Added each in-app purchase individually with correct Product IDs These IDs match exactly the ones in my .storekit file Filled out all required information: translations, pricing, descriptions Everything was filled correctly Submitted products for review: Each product went through the separate review process All products were approved individually Linked the approved products to my app build App submission: Uploaded new build with in-app purchases implemented Products are properly configured in the app code Used StoreKit for testing (products load correctly in sandbox) The Problem Even after all products are approved and linked to the build, reviewers are reporting that the products screen shows nothing - the products array appears to be empty for them. Since this is my first time submitting apps to the App Store, I feel like I'm missing some crucial step in the process. Apple's documentation seems scattered and not clear enough about the complete workflow. Questions: Do I need to do something special after products are approved but before submitting the app? Are there any additional configurations needed in App Store Connect? Is there a definitive step-by-step guide for the complete in-app purchase submission process? Does anyone have experience with this issue or know of clear documentation that explains the complete in-app purchase workflow from creation to app approval? Any help or pointers to proper documentation would be greatly appreciated!

Hi, I am in need of your help with publishing my game. I got the following explanation for the negative review of my app/game. Issue Description One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next Steps Update the local network information purpose string to explain how the app will use the requested information and provide a specific example of how the data will be used. See the attached screenshot. Resources Purpose strings must clearly describe how an app uses the ability, data, or resource. The following are hypothetical examples of unclear purpose strings that would not pass review: "App would like to access your Contacts" "App needs microphone access" See examples of helpful, informative purpose strings. The problem is that they say my app asks to allow my app to find devices on local networks. And that this needs more explanation in the purpose strings. Totally valid to ask, but the problem is my app doesn't need local access to devices, and there shouldn't be code that asks this?? FYI the game is build with Unity. Would love some help on how to turn this off so that my app can get published.

inapp purchase product has been in review for more than 24 hours, although we have another product that was submited for review after the first one and it has been approved already

Guideline 2.5.1 - Performance - Software Requirements The app uses or references the following non-public or deprecated APIs: Iobmobile Classes: • __SwiftValue The use of non-public or deprecated APIs is not permitted, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms. Can anyone she some light as to what __SwiftValue even means?

New developer here. Does removing your app from review(to change the build or any other reason), and resubmitting it, reset you to the back of the line? I‘ve done this multiple times, and I have users asking me when the updates are coming.

2026 confirmed that ASO has evolved beyond keywords into a full funnel system where creatives, conversion rate, app quality, retention, and ads drive visibility. Organic growth now comes mainly from Explore and Browse, with algorithms rewarding strong visuals and product health over simple metadata changes.

As an indie iOS dev, ASO often feels frustrating and unpredictable. Any proven tips, or is it just a grind we all face.

Requesting you all any recommendations for iOS ASO tools covering keyword research, metadata optimisation, competitor tracking, and A/B testing.

App Store Optimization in 2026 requires a more strategic, data driven approach as Apple’s algorithms evolve and user expectations continue to rise. This overview covers the key ASO trends iOS developers should focus on, including AI powered keyword insights, product page optimization, conversion focused testing, and advanced localization to drive sustainable organic growth.

I have been exploring App Store Optimization and noticed that Apple primarily uses the App Name, Subtitle, and Keyword field as the main text based ranking signals according to official and third party sources. Are these the only factors that truly impact iOS ASO, or do elements like the app description and promotional text indirectly influence visibility, conversion, or ranking updates over time, and how frequently should subtitles and keywords be revised after launch.

I’ve been building iOS apps since 2011, took a 4-year break, returned with two new apps, and it feels like organic visibility and indexing have changed drastically compared to earlier releases. Has anyone else noticed slower indexing, fewer automatic mentions, and almost zero organic traction—has discovery changed, or is it just saturation?

Hello, I have an app with a few essential asset packs currently totaling to ~8GB. I've noticed that when trying to install the app fresh from TestFlight, there is a significant delay between tapping install and the app appearing on the device in the loading state. The delay is long enough where it's hard to tell what's happening, or if the installation has failed. This also appears to be an issue in App Review, as I've had my app rejected twice due to the app not loading on the reviewers device. The reason they gave is UIRequiredDeviceCapabilities is blocking the installation, but UIRequiredDeviceCapabilities is empty. Note: I'm not looking for App Store review help, simply sharing the extent of the issue. Thank you

Hi everyone, my name is Donovan, I am sharing here the official response I received from Apple following my appeal with App Review Board (image attached). For context, I am an independent developer and a student, working alone. This application was originally created as a student project, with a very simple goal: to improve my skills in mobile application development and to understand the entire creation cycle, from the initial idea to a genuinely usable application. What was meant to be an exercise gradually became a real product. Over time, many people tested the project, used it, provided positive feedback, and encouraged me to take it all the way. That is why I decided to continue it, structure it properly, and finalize it with the level of seriousness expected from a public-facing application. Today, the application is a dating and social connection app, entirely free, with no blocking paid features, funded only by light and optional advertising. It follows the rules, works correctly, and offers features that Apple itself acknowledged as useful and informative. And yet, after review, the message is clear: it is not the quality that is being questioned, but the category. Because it is a dating app, a category considered saturated, two years of independent, self-funded work, carried out seriously and in compliance with the rules, can simply be dismissed. What is being judged here is not the work itself. It is the right to enter. The “unique and very high-quality experience” being required appears to be a threshold reserved for those who are already established, visible, or funded. For a serious student project carried by a single developer, the door remains closed, cleanly, politely, definitively. For those who still wish to see what the application looks like, I have attached a few images illustrating the interface and the main features. Unfortunately, this will likely be the only way to discover it on iOS. Under these conditions, the conclusion is pragmatic. Rather than continuing to defend the very existence of an honest and free project, it becomes more coherent to invest my energy where it is genuinely accepted. On its side, Android validated the project without difficulty. It still allows an independent developer to propose an idea, let it evolve, and bring it to completion without requiring prior success just to earn the right to try. It is therefore very likely that these two years of development will never make it to the App Store. Not out of frustration. Out of clarity. I am publishing this message not to provoke, but to inform other independent developers: Apple is a remarkable platform, provided you are already established on it. And this is a reality worth knowing before turning a student project into a life project. Screenshots:

We are planning to migrate our application from an iOS In‑App Purchase (IAP) subscription flow to an external web purchase flow. The intended user journey is: The user taps a “Subscribe” button in the app. The user is redirected to a web-based checkout to complete the purchase. The user returns to the app, and subscription access is unlocked based on entitlement verification from our backend. Our app is currently listed in the Education category. Before we begin this refactor, we would like confirmation on the following: Entitlements / permissions Do we need to request any specific Apple entitlements or approvals to implement this external purchase flow (e.g., external link or alternative payment related permissions)? Compliance / review requirements Are there any specific App Review compliance checks, disclosures, or review process requirements we must satisfy when moving from IAP to an external purchase flow? If relevant, are there constraints based on app category (Education) or product type (subscription)?